home *** CD-ROM | disk | FTP | other *** search
- Path: news.cube.de!news
- From: hhoff@cube.de (Holger Hoffstaette)
- Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
- Subject: Re: Will Java kill C++?
- Date: 17 Apr 1996 22:12:43 GMT
- Organization: Cube Informationssysteme GmbH
- Message-ID: <4l3qcr$8u3@cubenx.cube.de>
- References: <3134D499.653E@ix.netcom.com> <315BFB16.B74@isg.de>
- <4ku8rq$pav@cubenx.cube.de> <goochb.340.00156E50@rwi.com>
- NNTP-Posting-Host: intel1.cube.de
- X-Newsreader: RadicalNews (TM) 0.8.5 Beta(i)
-
-
- Sorry, a little late..
-
- William D. Gooch wrote:
- > In article <4ku8rq$pav@cubenx.cube.de> hhoff@cube.de (Holger Hoffstaette)
- writes:
- >
- > >William D. Gooch wrote:
- > >>
- > >> Gosh, hasn't this been discussed enough before? MI has
- > >> great value when used appropriately. Added complexity
- > >> and indirection in instance structures or redundant code
- > >> are essentially the only ways to compensate for its lack.
- >
- > >Yeah, it's also a great way of preventing you from fixing third-party
- > >classes that are Broken By Design(tm).
- >
- > What do you mean by "preventing?" MI is an added
- > capability, and prevents nothing that I can think of.
-
- Many of the C++ class libraries I've seen that use MI have serious
- problems - they either fall over at the slightest tip (trigger one
- extended part, see the rest of the heirarchy fall) or, even worse,
- are just *wrong* when it comes to the modeled class hierarchy.
- I can not 'untangle' the given mess by overriding or 'flattening' the
- inheritance hierarchy. Inserting a delegate can get you around this,
- but it usually leads to the bloat you mentioned if not done properly
- (i.e. carefully); you might end up inserting more delegations than you
- planned. SI systems are probably simpler (easier?) in this regard.
-
- > >Some of us have *real* protocols & forwarding, and get by great without
- > >unnecessary code bloat or weirdo design. MI - thanks, but: No Thanks!
- >
- > Certainly you are free to not use MI, whether or not the
- > language supports it. In my experience, properly used
- > MI helps in avoiding "code bloat," as I pointed out before.
-
- 'Properly' used - sure!
-
- > "Forwarding" (delegation) is an example of the indirection
- > I was referring to, and what you mean by "*real* protocols"
- > is not at all clear. (Apparently this is something that can't
-
- Forwarding is great and IMHO used way too little, maybe because many
- people don't know something like it exists, or how easy, yet powerful
- it is.
-
- By real protocols I meant protocols (interfaces, capabilities) that can
- be 'attached' to a class anytime, anywhere; they should be optionally
- inheritable, mixable without conflict, addressable and speakable over a
- wire (distributed objects). I use Objective-C and it comes pretty close
- (which has a lot to do with the environment I'm in (NEXTSTEP), but then
- again, that's no coincidence).
-
- My Smalltalk is a bit rusty (we -are- wasting c.l.s space, right? :), but
- I don't think you can ask an object if it conforms to a certain
- protocol/category/whatyoucallit; methods only, if I remember correctly.
- No way in C (now that would be fun) or C++. RTTI is little help, asking
- for or knowing a 'type' (the word tells) doesn't give me a clue whether
- the object I'm talking to actually knows what I'm talking about or not!
- I think what I'm trying to say is that capabilities/interfaces are good
- and too rigid hierarchies are bad. (cf. the follow-up by Matthias Blume).
-
- > be accomplished in a language which supports multiple
- > inheritance? Very interesting.)
-
- I'm not sure if MI in principal prevents something like I described above;
- it probably depends on the implementation and method dispatch semantics of
- the particular language.
-
- > You'll need to define "weirdo design" (is that a technical
- > term?) before I can respond to that part.
-
- When Holy Wars get tough, the techies get weirdo.
-
- Read: both MI and delegation/forwarding can be used easily to botch up
- royally (what's new?). MI can get you in the mud quickly and you can't
- get out anymore; excessive delegation can make you sink slowly, but
- surely. Your choice. :)
-
- I've had my head in large delegation-based systems (ObjC, Smalltalk)
- that virtually collapsed because of a system-wide broadcast (delegation)
- 'storm' that just never seemed to end, yet was necessary (or *thought* to
- be necessary) to keep the system in a consistent state. These I call
- 'weirdo' designs, since they usually show that the corresponding project
- has gone insane: prime directive #1 is to try to catch up with a design
- mistake made in the beginning, although you *know* that it cannot be caught
- and fixed without major surgery.
-
- > Truly folks, I had no intention of starting a flamefest here.
- > I am at a complete loss to understand the vehemence with
- > which some people appear to dislike multiple inheritance.
-
- I once had a look at Taligent's 'frameworks', which use(d?) mix-in
- classes (probably the most often use for MI) excessively.
- The whole thing was about as readable as a brick in the face. IT HURT.
- Maybe I was just too dumb for it, but then again, it was probably too
- hard for the other 98% of the programming world, too!
- It certainly seemed to be too hard for the guy doing the presentation,
- trying to explain what it was all about.
-
- > My experience with it has been quite good (and I have also
- > learned to do fine without it, since I am currently working
- > in Smalltalk). If there is something substantive behind this
- > very emotional reaction, it has yet to become clear to me.
- > If someone can explain this in terms other than "many
- > people use MI badly," I would really appreciate it.
-
- Today, a disproportionately large amount of code is still written by people
- who have no or only insufficient CS education, nor intensive OO training;
- they were electricians, salespeople, teachers or physicians in previous
- lives, and usually grunt COBOL or VisualBasic (if they're really advanced).
- Now that's fine, but letting these people play with MI (preferrably in C++
- after a 'Learn The Magic of OO Really Fast In 5 Days Because The Boss Told Us'
- is like giving them a bazooka to swat a fly. Granted: this is very emotional
- and absolutely no reason for an *objective* view on MI, but it is nevertheless
- a very real one. Before someone tells me that this is no reason to take away
- the Sharp Knives from The Experts: I agree!
-
- Interestingly enough, these more 'naive' users of C++ use MI to simply
- add functionality, just like mix-ins. Of course, neither do they know that
- they're using mix-ins, nor are the trunk class or its mix-ins properly thought
- out, but that has never stopped anybody, right?
-
- > I do think there's a serious lack of adequate instruction on
- > the proper use of MI. Perhaps this can be rectified.
-
- I too would certainly like to see some *good* examples where MI fits in,
- properly modeling a certain domain problem. Code NOT written in C++ gets
- bonus points!
-
- By the way: should'n this go into comp.object (only)?
-
-
- Regards,
-
- Holger
- (playing devils' advocate ;)
- --
- ___
- /\__\ Holger HoffstΣtte net: hhoff@cube.de (MIME, NeXT, PGP)
- \/__/ Cube Informationssysteme GmbH vox: (+49)0711-90669-0 (or -11)
- [kju:b] Stuttgart, Germany fax: (+49)0711-90669-16
-
-